在軟體開發前，團隊常先整理產品需求文件（PRD），再形成系統與軟體需求規格。文件名稱可能因組織而異；關鍵是讓需求、設計與查證證據能相互追溯。

從產品的角度出發，PRD 可描述使用者需求、商業價值、功能特性、使用者介面（UI）行為與業務邏輯；系統需求與軟體需求則進一步定義產品應具備的能力，以及軟體應呈現的可查證行為。

在醫療軟體中，我們會先界定預期用途，再依目標使用者、使用情境、系統需求與風險分析建立規格。譬如，一個顯示血氧值的 App 收到增加警報的需求時，不能直接套用一組通用的血氧分級作為警報門檻。團隊需要先釐清警報要提醒誰、適用哪些患者與量測情境，再依臨床證據、量測誤差及風險分析，訂出觸發條件、持續時間、訊號品質不足時的處理方式與警報內容。血氧讀值是估計值，單次數值也不能取代症狀與變化趨勢的判斷。這些條件應寫入需求並建立可查證的判準；若需求無法查證，就難以提出它已正確實現的證據，但通過測試本身也不能單獨證明整體產品安全。

規格轉譯 4 階層架構

參考 IEC 62304 的軟體生命週期流程，以及 ISO 13485 的設計開發要求，可以用以下四個層次整理需求與證據。這是便於說明的實務架構，不是標準規定的固定四階層：

[ 1. 預期用途 Intended Use ]  ➔ 產品邊界與法規定位
         │
         ▼
[ 2. 使用者需求 User Needs ]  ➔ 臨床情境與使用者目的
         │
         ▼
[ 3. 軟體需求 SRS ]            ➔ 輸入輸出、驗收邏輯、異常處理
         │
         ▼
[ 4. 查證與確效證據 ]       ➔ 規格查證、使用者需求與預期用途確效

• 第一層：預期用途（Intended Use）
  • 定義與定位：宣告軟體要解決什麼問題、給誰用、在哪用，以及「非目標（Non-goals/Limitations）」
• 第二層：使用者需求（User Needs）
  • 定義與定位：從臨床或使用者視角出發，說明使用者為了達成預期用途，在操作情境中「必須能完成什麼事」。
• 第三層：軟體需求規格(Software Requirements Specification, SRS)
  • 定義與定位：依據系統需求與風險控制要求，定義精確的軟體行為；IEC 62304 Clause 5.2 涉及軟體需求分析。
  • 撰寫規格時可考慮的要素（依產品與風險選用，以下並非 IEC 62304 5.2.2 的逐項清單）：
    1. 輸入與輸出規格：欄位型態、資料格式、合理區間（Ranges）、預設值。
    2. 風險控制措施：由 ISO 14971 風險分析導出的軟體控制要求，例如必要的阻擋或防呆邏輯。
    3. 異常與缺失處理：網路斷線、欄位漏填或無效數值時的系統行為。
    4. 可追溯與可查證性：使用唯一 ID（如 SRS-001）管理需求，寫清楚可判定的結果。唯一 ID 是實務管理方式，不應誤寫為該條文指定的格式。
• 第四層：查證與確效證據
  • 查證（Verification）：確認軟體輸出符合已定義的需求。IEC 62304 Clause 5.7 涉及軟體系統測試；測試案例可記錄輸入條件、預期結果與通過／失敗判準。Given–When–Then 是一種可選的寫法，並非標準指定格式。
  • 確效（Validation）：確認完成的產品在預期使用情境中，符合使用者需求與預期用途；不能僅以軟體需求測試取代。

建立需求追溯矩陣 RTM (Requirements Traceability Matrix)

什麼是 RTM 呢？

RTM 是管理需求、風險控制與查證／確效證據的工具。它協助團隊建立並檢查「由上至下、由下至上」的雙向可追溯性（Bidirectional Traceability）；矩陣中的連結仍須由實際紀錄支持。

RTM 的核心目的與價值包含：

1. 檢查需求與證據的完整性：連結預期用途、使用者需求、系統及軟體需求、設計輸出、風險控制、查證與確效證據。並非每項預期用途都要直接對應一段程式碼。
2. 落實風險控制：追溯相關危害、危險情境與風險控制措施，確認分配到軟體的控制要求已實現，並檢查其有效性證據。
3. 變更管理與影響分析 (Impact Analysis)：當程式碼、第三方 SOUP 套件或需求發生變更時，團隊能透過 RTM 快速向上與向下追溯，精準定位受影響的模組、測試腳本與風險評估項目。
4. 及時找出開發缺口 (Gap Analysis)：協助團隊找出無法追溯至需求或設計的功能、缺少查證證據的需求，或缺少有效性證據的風險控制措施。

小結

醫療軟體開發需要跨部門合作：產品、臨床、風險管理、工程與品質團隊共同釐清預期用途和使用者需求，再將其轉化為系統與軟體需求，規劃查證及確效。上述四個層次可幫助團隊整理文件與追溯關係，但它們不是 IEC 62304 指定的四階層流程。RTM 可用來找出缺口；要判斷需求是否完成、風險是否受控，仍需檢查測試結果、風險管理紀錄、設計審查與確效證據。